Before it can be merged can you fix the missing newline (see ci check)

@DannyvdSluijs not sure if it is a stupid question but do you think it is possible to auto generate the getters for the child collection items? Or is there something different between the various models and their relations making this a piece of logic that needs to be added on a per-model situation?

@DannyvdSluijs not sure if it is a stupid question but do you think it is possible to auto generate the getters for the child collection items? Or is there something different between the various models and their relations making this a piece of logic that needs to be added on a per-model situation?

That is actually a good suggestion. At this point I’m not sure if this can be done easily. I do know that non generated code is being kept when regenerating. So there is nothing blocking adding an additional getter as a short term fix.

When I have time available I can look into the generating code and see if we can add collection getters.

One other idea I’m having (but struggling to find the time for) is to have the manual work I do frequent updates turned into a GitHub workflow.

Get it. Understand it is a bit hard to find the time for this. Was more thinking out loud based on this stalled PR.

@remkobrenters I've been playing around with this idea as you triggered me. One thing I came to realise, is the info that is needed to generate the correct code consists out of the following:

1. The fact that it is an internal relation, this can be done based on the lack of en EDM. prefix from type value taken from the EOL documentation
2. The corresponding model, this should also be doable from the type value
3. The type of relation, is it a one-to-one, one-to-many (or even a many-to-many if that is possible?). Perhaps we can still derive this in an automated way
4. How to specify the correct filter expression (e.g. "EntryID eq guid'{$this->EntryID}'") this is where I am stuck ATM.

So this is me giving a status update and not seen an easy solution. So perhaps you can think of something or internally check if there is an "expert" on the deferred properties?

One final piece of info that I just ran into is commit f527c4f, adding a protected lazyLoad method)which might also be an option to explore. But that requires me to setup a proper client id/secret which I don't have at this point.

Eager to hear your thoughts.

I think we should be able to join your thoughts about this but we are in a bit of a hectic time here for the upcoming weeks. I will discuss this and we will take a crack at this as it feels it is very possible to automate this in a good way.

I believe that the deferred relation methods can indeed be generated. Not sure how the generator works and in which language it is written, but looking a the endpoints in https://start.exactonline.nl/docs/HlpRestAPIResources.aspx, it seems that all needed information is available in order to determine the one or many relation and it's key.

For example the fields in the SalesOrders resource: the title of a relation contains a link to the related resource, this link can be used to determine the target.

The description always contains "Collection of ..." for one-to-many relationships, which allows you to know the type.

The key name of a relationship for a one-to-one is always the Primary key of the target, and for one-to-many, it's always the Primary key of the source (current) resource.

Here's an example from SalesOrders:

• SalesChannel is a one-to-one relationship, uuid in the SalesOrders resources and the Primary key from the SalesChannels is the ID.
• SalesOrderLines is a one-to-many relationship, the OrderID Primary key from the SalesOrders resource can be used to resolve this.

How to specify the correct filter expression (e.g. "EntryID eq guid'{$this->EntryID}'") this is where I am stuck ATM.

Maybe it's an idea to resolve the related Entity class and use the $primaryKey property?